Sumo Logic で APM をやってみる

酒井剛

2023.06.18

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Sumo Logic ではログの収集と分析だけでなく、メトリクスやトレースも収集し、アプリケーションのパフォーマンスを測定することを目的（APM）として活用することができます。

このトレースは、アプリケーションが処理するリクエストやトランザクションの経過を観察して、アプリケーションのパフォーマンスに影響するボトルネックやバグなどの原因を特定することができます。
マイクロサービスのような複数のサービスで構成されるシステムでは、１つのリクエストが複数のサービスをまたいで処理されることにより、リクエスト全体の処理の流れを把握するのが難しくなります。
トレースによって個々の処理の流れを追跡し、サービスの依存関係・サービスのレイテンシーを可視化し問題となっている箇所の特定や追求することに役立てることができるわけです。

Sumo Logic のライセンス

トレースを利用できるライセンスは、Essentials（5GB/1日まで）、Enterprise Operations、Enterprise Suite になります。
PoC用途であれば、FreeまたはTrialでも制限つきで利用することが可能です。

ライセンスと機能表：

とりあえずやってみる

Sumo Logic でトレースをとるとどんなふうに見えるのか、まずはサンプルのアプリケーションを使ってやってみたいと思います。
Sumo Logic の公式ドキュメントでは、ここに Sumo Logic の設定方法とサンプルのアプリケーションのリンクがあるので、こちらを参考にやってみます。

今回のアーキテクチャ

Sumo Logic では OpenTelemetry によってトレースを取得していくことになります。
OpenTelemetry では下記の３パターンの実装方法に分かれるかと思います。
下にいくに連れて、実装の容易性とトレードオフに送信するデータの欠損など完全性が担保されるかたちになります。

コレクターなし
エージェント型
ゲートウェイ型

今回は Sumo Logic が用意しているサンプルのDockerイメージを利用していきますが、コレクターなしの下記のようなアーキテクチャになります。

Sumo Logic のソース設定

まずソースの設定です。
Sumo Logic の HTTP Tracesソースを設定します。このソースでは Zipkin JSON v2 または OTLP/HTTP のスパンに対応していて、トレースデータをHTTPエンドポイントで受信するためのソースになります。

Managed Data の Collection で Hosted Collector からソースを作成します。※以前にコレクターを作成していない場合や、はじめて Sumo Logic を開始される方はコレクターの作成が必要です。

ここでは HTTP Traces を選択します。

ソースの設定では、任意のソース名と任意のソースカテゴリー名をつけます。

ソースカテゴリーの詳細についてはこちらをご覧ください：

設定を保存した後に、ソースの「Show URL」から受信用のHTTPエンドポイントが表示されるので、コピーします。アプリケーションがトレースを送信する先として設定するのに使います。

サンプルアプリケーションを Docker で展開する

こちらのサンプルアプリケーションを Docker で起動します。※MacのM1プロセッサのPCだとコンテナが起動しなかったので、WindowsのIntelプロセッサのPCで起動させています。

export OTLP_ENDPOINT_URL=<さっきコピーしたURL>

docker run --rm --name ot-petclinic -p 8080:8080 \
    --env JAVA_TOOL_OPTIONS="-javaagent:/agent/opentelemetry-javaagent.jar" \
    --env OTEL_SERVICE_NAME=petclinic-svc \
    --env OTEL_RESOURCE_ATTRIBUTES=application=petclinic-app \
    --env OTEL_METRICS_EXPORTER=otlp \
    --env OTEL_TRACES_EXPORTER=otlp \
    --env OTEL_EXPORTER_OTLP_ENDPOINT=${OTLP_ENDPOINT_URL} \
    --env OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf \
    public.ecr.aws/sumologic/opentelemetry-petclinic:latest

localhostの8080ポートでjavaアプリが動作するので、色々とアクセスしてみます。

トレースデータを Sumo Logic のトレースクエリやダッシュボードで見てみる

トレースクエリ

トレースデータは、「+New」の「Traces」から確認することができます。

検索時間を広げてみてもトレースでデータが確認できない場合は、ログ検索で下記のコマンドで検索してみてください。エラーなどが発生している場合はここで確認することができます。

_index=sumologic_system_events AND _sourceCategory=tracingIngest

エラーの出力が確認された場合は、ここからFAQを確認することもできます。

「Traces」の検索画面では、先程のWebアプリケーションをブラウザ上で操作していた内部的なトランザクションが一覧表示されます。
試しに一つクリックすると、そのトレースの詳細を表示することができます。

このトランザクションから、全体の処理に46.75msかかって、フロントエンドのアプリとDBが連携をしていて、それぞれどの処理がどれだけの時間がかかったか、どういう風に処理が遷移したか確認することができます。
アプリケーションの処理をオペレーション単位でデータを取得し、前後関係や処理するのに実際にかかった時間を見ることができるのは非常に素晴らしいですね。これだけでもボトルネックが発生していた場合、コードの修正や原因の特定に役立てれそうです。

APMダッシュボード

トレースデータを Sumo Logic に取り込むと、自動的にAPMダッシュボードが利用できるようになっています。
APMダッシュボードは、「+New」の「Explorer」から確認することができます。

「Explore by」のところで、APM に関するダッシュボードが表示されるようになります。
Sumo Logic では OpenTelemetry によってトレースデータを収集することができます。OpenTelemetry のアプリケーションへの実装時に設定値として渡した、アプリケーション名、サービス名、環境名ごとの視点でダッシュボードを切り替えることができます。

APM:Application View だと、アプリケーションを起点にレイテンシーやリクエストの状況を把握することができます。
さらに、左ペーンでは階層上にアプリケーション内のサービスに絞ったダッシュボード、さらに環境に絞ったダッシュボード、オペレーションに絞ったダッシュボードといった感じで、視点をフォーカスして原因を見ていくことができます。

広い視点から、統計的にドリルダウンができるので素早く当たりをつけて、MTTRの削減が期待できそうです。

まとめ

以上、Sumo Logic でトレースを取得し APM として分析するためのトレースクエリやダッシュボードを試してみました。
もともと Sumo Logic はSIEMとしてのログ分析に強みを持っているソリューションでありますが、ワンプラットフォームでメトリクス・トレースを取り込みAPMツールとしても十分に活躍することができそうです。
APMの領域においても、最終的な原因分析はログの確認になってくるので、SIEMとしてログ分析の柔軟性に長けた Sumo Logic の特徴が活かせそうです。